home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 4.8 KB | 100 lines | [TEXT/GEOL] |
- Item 5411218 9-April-90 08:00PDT
-
- From: D2458 Tactics Int'l, David Shillito,PRT
-
- To: MACAPP.TECH$ MacApp Technical
-
- Sub: THINK 3.0 suggestions
-
- Item 4616205 8-April-90 16:25PDT
-
- From: D2458 Tactics Int'l, David Shillito,PRT
-
- To: NEAL Symantec, David Neal,PRT
-
- cc: AUST0338 AUPtnr - Tactics Int'l,Shillito,IDV
-
- Sub: THINK 3.0 suggestions
-
- David,
-
- Thank you again for your continued help.
-
- My link problems with DebugDebugStr and DebugException WERE INDEED related to
- beta software: I still had old versions of the THINK MacApp “Diffs” and
- “Templates” folders lying around instead of the final release ones!!! It
- didn't occur to me that those had anything with the MacApp source conversion
- process until I reread your MacApp manual appendix. So Link is well now, and
- I'm sorry about that episode.
-
- All busy cursor problems have been resolved with the insertion of {$IFC
- qBusyCursor} ... {$ENDC} in all our busy cursor unit's procedures.
-
- I am now able to run in THINK Pascal's environment. It seems to execute our
- application without any problems, so far, and I CAN now run under MultiFinder.
- This last problem may have been memory-related (see the last paragraph below).
- Given the size and complexity of our software, this says a lot for THINK's
- environment.
-
- However, I can't use the built versions yet as they crash in the initialization
- stage, where I am still doing some investigating. I did resolve an earlier
- problem which had to do with the SANE library (see item 1 below).
-
- Here are a few suggestions from someone who has had to deal a lot with project
- file organization during the last several days:
-
- 1) Could your documentation mention to pay close attention to modifying the
- seed projects to replace SANELib.lib with SANELib881.lib in the case where the
- 68881 option is turned on? This is particularly important since you provide
- seed projects which contain SANELib.lib in them.
-
- 2) More generally, could we be warned that the seed projects are GENERAL
- and that modified “seeds” are required anytime one's compiler options differ
- from the default, or release, options?
-
- 3) I think it should be mentioned somewhere that anytime a rebuild of a
- large (e.g. MacApp) project is pending (for example, after a change in compiler
- options), it is much more efficient and just plain faster to first do a Remove
- Objects! Can this tidbit also be included in your documentation?
-
- 4) Because of 1-3, I find that it is NOT worth keeping prebuilt seed
- projects around: they take up too much space (for all 4, probably over 2
- megabytes) and in many cases the compiler options are going to change and thus
- necessitate a rebuild anyway. After all, on an 8-meg Mac IIx and the objects
- removed, recompiling all of MacApp takes me about 7 minutes (this from memory,
- not actually measured)!
-
- 5) Long project files are excruciatingly slow to scroll when dragging
- entries around (especially in the segment view, although they somehow get
- faster the closer you get to the main segment, near the top). I think this
- design philosophy served you well until you undertook MacApp. Applications
- with such large numbers of files and segments have exposed the need to
- reevaluate this user interface issue.
-
- 6) The above is made much worse by the fact that you don't allow multiple
- selections on file or segment entries. I realize that multiple selections
- would probably require some tricky user interface stuff, but why shouldn't
- someone be allowed to drag or remove multiple files/segments? Dragging
- multiple segment entries from distinct segments could get quite involved, but
- it must be doable.
-
- 7) With the lack of multiple selections, put in a command key equivalent
- for Remove in the Project menu (perhaps Cmd-“minus sign”).
-
- Finally, I can no longer replicate the compiler crasher case. As you may
- recall, our largest source file (UTDoc.p) was over 8,000 lines of code and I
- have since broken it up into 2 files (UTDoc1.p and UTDoc2.p) by divying up the
- doc's methods between them. In addition, I have been using a much larger
- MultiFinder partition size for THINK Pascal since I have been able to execute
- within the THINK environment (our application requests 2500K of heap space). I
- have just retried combining the 2 source files into one large one and resetting
- the partition size to your default 2048, but unfortunately (or fortunately,
- from your point of view) no crash. This may point to a low-memory type of
- problem in the original crash set-up. Could it make sense in the case of the
- statement with empty sets I sent you then, i.e. could that statement have
- caused some sort of compiler memory shortage given that a very large source
- file was open?
-
- Yvon
-
-